PDG/TTG Overview

 

 

This chapter contains general overview information about the Packet Data Gateway/Tunnel Termination Gateway (PDG/TTG), including:

 

•	Product Description

•	Product Specifications

•	Network Deployment(s) and Interfaces

•	Features and Functionality

•	Features Not Supported in This Release

•	How the PDG/TTG Works

•	Supported Standards

 

Product Description

The Cisco® ASR 5000 Chassis provides 3GPP mobile operators with a flexible solution that functions as a Packet Data Gateway/Tunnel Termination Gateway (PDG/TTG) in 3G UMTS wireless data networks. The PDG/TTG consists of new software for the ASR 5000.

The PDG/TTG enables mobile operators to provide Fixed Mobile Convergence (FMC) services to subscribers with dual-mode handsets and dual-mode access cards via WiFi access points. The PDG/TTG makes it possible for operators to provide secure access to the operator’s 3G network from a non-secure network, reduce the load on the macro wireless network, enhance in-building wireless coverage, and make use of existing backhaul infrastructure to reduce the cost of carrying wireless calls.

This PDG/TTG software release provides both PDG and TTG functionality.

The PDG is a network element that provides WLAN-to-3GPP network interworking. This interworking is achieved by the subscriber UEs in the WLAN initiating an IKEv2/IPSec tunnel toward the PDG, which functions as a security gateway that provides the UEs a secure connection to the Packet Data Network (PDN).

The TTG is a network element that enables PDG functionality for existing GGSN deployments. The TTG and a subset of existing GGSN functions work together to provide PDG functionality to the subscriber UEs in the WLAN.

 

Summary of PDG/TTG Features and Functions

The TTG features and functions include:

 

•	PDG service

•

PDG mode

•

TTG mode

•	IKEv2 and IP Security (IPSec) encryption

•	Multiple digital certificate selection based on APN

•	Subscriber traffic policing for IPSec access

•	DSCP marking for IPSec access

•	WLAN access control

•	RADIUS and Diameter support

•	EAP fast re-authentication

•	Pseudonym NAI support

•	Multiple APN support for IPSec access

•	Lawful intercept

•	IMS emergency call handling

•	Session recovery support

•	Congestion control

•	Bulk statistics

•	Threshold crossing alerts (TCAs)

•	DIAMETER authentication/authorization support

•	QCI-level QoS configuration support

•	AAA mediation accounting and offline charging

 

Product Specifications

The following information is located in this section:

 

•

Licenses

•	Hardware Requirements

•	Operating System Requirements

 

Licenses

The PDG/TTG is a licensed product. For information about PDG/TTG licenses, contact your sales representative.

 

Hardware Requirements

Information in this section describes the hardware required to run the PDG/TTG software.

 

Platforms

The PDG/TTG operates on the ASR 5000.

 

Components

The following application and line cards are required to support the PDG/TTG on the ASR 5000:

 

•	System Management Cards (SMCs): Provides full system control and management of all cards within the ASR 5000. Up to two SMCs can be installed; one active, one redundant.

•	Packet Services Cards (PSCs/PSC2s/PPCs): Provide high-speed, multi-threaded PDP context processing capabilities for 2.5G and 3G services. Up to 14 packet processing cards can be installed, allowing for multiple active and/or redundant cards.

•	Switch Processor Input/Outputs (SPIOs): Installed in the upper-rear chassis slots directly behind the SMCs, SPIOs provide connectivity for local and remote management and for central office (CO) alarms. Up to two SPIOs can be installed; one active, one redundant.

•

Ethernet 10/100 and/or Ethernet 1000 Line Cards: Installed directly behind packet processing cards, these cards provide the physical interfaces to elements in the operator’s network. Up to 26 line cards should be installed for a fully loaded system with 13 active packet processing cards, 13 in the upper-rear slots and 13 in the lower-rear slots for redundancy. Redundant packet processing cards do not require line cards.

•

Redundancy Crossbar Cards (RCCs): Installed in the lower-rear chassis slots directly behind the SMCs, RCCs utilize 5 Gbps serial links to ensure connectivity between Ethernet 10/100 or Ethernet 1000 line cards and every packet processing card in the system for redundancy. Two RCCs can be installed to provide redundancy for all line cards and packet processing cards.

Important: Additional information pertaining to each of the application and line cards required to support GPRS/UMTS wireless data services is located in the Hardware Platform Overview chapter of the Product Overview Guide.

 

Operating System Requirements

TTG functionality is available for the ASR 5000 running StarOS Release 9.0 or later.

PDG functionality is available for the ASR 5000 running StarOS Release 11.0 or later.

 

Network Deployment(s) and Interfaces

This section describes the PDG/TTG as it functions in a GPRS/UMTS data network.

 

The PDG in a GPRS/UMTS Data Network

The PDG is a network element that provides WLAN-to-3GPP network interworking. This interworking is achieved by the subscriber UEs in the WLAN access network initiating an IKEv2/IPSec tunnel to the 3GPP PDG, which functions as a security gateway that provides the UEs a secure connection to the Packet Data Network (PDN) or Internet.

The following figure shows a sample PDG implementation.

Sample PDG Implementation

In the implementation above, the subscriber UEs first gain access to the WLAN via a Wi-Fi access point. The UEs get an IP address from the WLAN and use this IP address for communication over the access IP network. To gain access to the PDN/Internet, the UEs use IKEv2 protocol to request a secure IPSec tunnel from the PDG. The UEs may get the IP address of the PDG either from a statically configured IP address, or they may use DNS resolution. During IKEv2 negotiation, the PDG allocates a remote IP address for each subscriber UE to use to access the PDN/Internet. The PDG binds each UE’s local IP address with its allocated remote IP address.

The authorization decision for tunnel establishment for access to a 3GPP W-APN belongs to the 3GPP AAA server. Upon authorization, the PDG terminates a secure IPSec tunnel for each WLAN UE subscriber session established over the Wu reference point. The PDG also establishes a corresponding connection over the Wi reference point toward the PDN/Internet.

 

The TTG in a GPRS/UMTS Data Network

The TTG is a GPRS/UMTS network element that enables the implementation of PDG functionality in existing GGSN deployments. It achieves this by using a subset of the Gn reference point called the Gn' (Gn prime) reference point to connect to currently-deployed GGSNs. This provides the means by which GPRS mobile operators can offer new services to current subscribers by implementing PDG functionality using existing infrastructure.

The following figure shows a PDG implementation that consists of the TTG working together with a currently-deployed GGSN. In this implementation, only a subset of the GGSN functionality is used.

The TTG and GGSN in a PDG Implementation

In the implementation above, the TTG terminates a secure IPSec tunnel for each WLAN UE subscriber session established over the Wu reference point. The TTG also establishes a corresponding GTP (GPRS Tunneling Protocol) tunnel over the Gn' reference point to the GGSN. The TTG and the subset of GGSN functions work together to provide PDG functionality to the UEs in the WLAN.

The TTG functions as an SGSN in the GPRS/UMTS network to provide an SGTP (SGSN GPRS Tunneling Protocol) service. The SGTP service enables the TTG to use GTP over the Gn' interface to carry packet data between itself and the GGSN. The GGSN establishes a corresponding connection over the Gi reference point toward the PDN/Internet.

 

PDG/TTG Logical Network Interfaces (Reference Points)

The following table provides descriptions of the logical network interfaces supported by the PDG/TTG in a GPRS/UMTS data network.

PDG/TTG Logical Network Interfaces

Interface	Description
Wu	The Wu reference point is located between the WLAN UE and the PDG/TTG. The Wu interface carries the secure IPSec tunnels between the UEs in the WLAN and the PDG/TTG. The IPSec tunnels carry the ESP (Encapsulating Security Payload) packets between the UEs and the PDG/TTG.
Wm	The Wm reference point is located between the 3GPP AAA server and the PDG/TTG. The PDG/TTG uses this reference point to retrieve tunneling attributes and UE IP configuration parameters.
Wi (PDG mode only)	The Wi reference point is located between the PDG and the Packet Data Network (PDN) for WLAN IP access.
Gn' (TTG mode only)	The Gn' reference point is located between the TTG and the GGSN. To provide PDG functionality in existing GGSN deployments, the TTG functions as an SGSN. For every IPSec tunnel that is established between the TTG and a WLAN UE, the TTG initiates a PDP context and a corresponding GTP tunnel over the Gn' interface to the GGSN. The TTG forwards the W-APN and IMSI of the WLAN UE to the GGSN in the Create-PDP-Context-Request message. The following messages are supported over the Gn' reference point: • Create PDP Context Request / Response • Update PDP Context Request / Response • Delete PDP Context Request / Response • Error Indication • Version Not Supported • GTP Payload Forwarding • GTP Echo
Gi (TTG mode only)	The Gi reference point is located between the GGSN and the Packet Data Network (PDN) for WLAN IP access when the PDG/TTG is in TTG mode.

‌

 

Features and Functionality

This section describes the features and functions supported by the PDG/TTG software.

The following features are supported and described in this section:

 

•	PDG Service

•

PDG Mode

•

TTG Mode

•	IKEv2 and IP Security (IPSec) Encryption

•	Multiple Digital Certificate Selection Based on APN

•	Subscriber Traffic Policing for IPSec Access

•	DSCP Marking for IPSec Access

•	WLAN Access Control

•	RADIUS and Diameter Support

•	EAP Fast Re-authentication Support

•	Pseudonym NAI Support

•	Multiple APN Support for IPSec Access

•	Multiple Authentication Support

•	Lawful Intercept

•	IMS Emergency Call Handling

•	Session Recovery Support

•	Congestion Control

•	Bulk Statistics

•	Threshold Crossing Alerts

•	AAA Mediation and Offline Charging

 

PDG Service

The PDG service provides both PDG and TTG functionality, operating in either PDG mode or TTG mode. The PDG service enables the UEs in the WLAN to connect with the core network elements via a secure IPSec interface.

During configuration, you create the PDG service in a PDG context, which is a routing domain on the ASR 5000. PDG context and service configuration includes the following main steps:

•	Configure the IPv4 address for the service: This is the IP address of the TTG to which the UEs in the WLAN attempt to connect, sending IKEv2 messages to this address to establish IPSec tunnels.

•	Configure the name of the crypto template for IKEv2/IPSec: A crypto template is used to define an IKEv2/IPSec policy. It includes IKEv2 and IPSec parameters for keepalive, lifetime, NAT-T, and cryptographic and authentication algorithms. There must be one crypto template per PDG service.

 

•	The name of the EAP profile: The EAP profile defines the EAP authentication method and associated parameters.

•	Multiple authentication support: Multiple authentication is specified as a part of crypto template configuration.

•	IKEv2 and IPSec transform sets: Transform set defines the negotiable algorithms for IKE SAs and Child SAs to enable calls to connect to the PDG/TTG.

•	The setup timeout value: This parameter specifies the session setup timeout timer value. The PDG/TTG terminates a UE connection attempt if the UE does not establish a successful connection within the specified timeout period.

•	Max-sessions: This parameter sets the maximum number of subscriber sessions allowed by this PDG service.

 

PDG Mode

The PDG mode of operation uses IKEv2/IPsec tunnels to deliver packet data services over untrusted Wireless Local Area Networks (WLANs) with connectivity to the Internet or managed networks.

In PDG mode, the system terminates an IPSec tunnel for each WLAN UE subscriber session established over the Wu reference point. The PDG also establishes a corresponding GTP (GPRS Tunneling Protocol) tunnel over the Wi reference point to the Packet Data Network (PDN).

 

TTG Mode

The TTG mode of operation uses IKEv2/IPsec tunnels to deliver packet data services over untrusted WLANs with connectivity to the Internet or managed networks.

In TTG mode, the system terminates an IPSec tunnel for each WLAN UE subscriber session established over the Wu reference point. The TTG also establishes a corresponding GTP tunnel over the Gn' reference point to the GGSN. The TTG and a subset of GGSN functions work together to provide PDG functionality to the WLAN UEs. In this configuration, the GGSN sees the TTG as an SGSN, and no additional changes are required at the GGSN to support this functionality.

 

IKEv2 and IP Security (IPSec) Encryption

The PDG/TTG supports IKEv2 and IPSec encryption using IPv4 addressing. IKEv2 and IPSec encryption enables network domain security for all IP packet-switched networks in order to provide confidentiality, integrity, authentication, and anti-replay protection. These capabilities are insured through use of cryptographic techniques.

IKEv2 and IP Security (IPSec) encryption includes the following options:

•	IKEv2 encryption protocols: AES-CBC with 128 bits, AES-CBC with 256 bits, 3DES-CBC, and DES-CBC

•	IKEv2 pseudo-random functions: PRF-HMAC-SHA1, PRF-HMAC-MD5

•	IKEv2 integrity: HMAC-SHA1-96, HMAC-MD5

•	IKEv2 Diffie-Hellman groups: 1, 2, 5, and 14

•	IPSec ESP (Encapsulating Security Payload) encryption: AES-CBC with 128 bits, AES-CBC with 256 bits, 3DES-CBC, and DES-CBC

•	IPSec integrity: HMAC-SHA1-96, HMAC-MD5

•	IKEv2 and IPSec rekeying

 

Multiple Digital Certificate Selection Based on APN

Selecting digital certificates based on Access Point Name (APN) allows you to apply digital certificates per the requirements of each APN and associated packet data network. A digital certificate is an electronic credit card that establishes a subscriber’s credentials when doing business or other transactions on the Internet. Some digital certificates conform to ITU-T standard X.509 for a Public Key Infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509 specifies standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.

During session establishment, the PDG/TTG can select a digital certificate from multiple certificates based on the APN. The selected certificate is associated with the APN that the WLAN UE includes in the IDr payload of the first IKE_AUTH_REQ message.

When configuring APN-based certificate selection, ensure that the certificate names match the associated APNs exactly. The PDG/TTG can then examine each APN received in the IDr payload and select the correct certificate.

The PDG/TTG generates an SNMP notification when the certificate is within 30 days of expiration and approximately once a day until a new certificate is provided. Operators need to generate a new certificate and then configure the new certificate using the system’s CLI. The certificate is then used for all new sessions.

 

Subscriber Traffic Policing for IPSec Access

Traffic policing allows you to manage bandwidth usage on the network and limit bandwidth allowances to subscribers. QoS configurations are stored per QCI level (Quality of Service class identities.

Traffic policing enables the configuration and enforcement of bandwidth limitations on individual subscribers of a particular traffic class in a 3GPP service. Bandwidth enforcement is configured and enforced independently in the downlink and uplink directions.

When configured in the Subscriber Configuration Mode of the system’s CLI, the PDG/TTG performs traffic policing. However, if the GGSN changes the QoS via an Update PDP Context Request, the PDG/TTG uses the QoS values from the GGSN.

Per RFC 2698, a Token Bucket Algorithm is used to implement the traffic policing feature on the PDG/TTG. The following criteria is used when determining how to mark a packet:

•	Committed Data Rate (CDR): The guaranteed rate (in bits per second) at which packets can be transmitted/received for the subscriber during the sampling interval. Note that the committed (or guaranteed) data rate does not apply to the Interactive and Background traffic classes.

•	Peak Data Rate (PDR): The maximum rate (in bits per second) that subscriber packets can be transmitted/received for the subscriber during the sampling interval.

Using negotiated QoS data rates, the system calculates the burst size, which is the maximum number of bytes that can be transmitted/received for the subscriber during the sampling interval for both committed and peak rate conditions. The committed burst size (CBS) and peak burst size (PBS) for each subscriber depends on the guaranteed bit rate (GBR) and maximum bit rate (MBR) respectively. This represents the maximum number of tokens that can be placed in the subscriber’s “bucket”. The burst size is the bucket size used by the Token Bucket Algorithm.

Tokens are removed from the subscriber’s bucket based on the size of the packets being transmitted/received. Every time a packet arrives, the system determines how many tokens need to be added (returned) to a subscriber’s CBS (and PBS) bucket. This value is derived by computing the product of the time difference between incoming packets and the CDR (or PDR). The computed value is then added to the tokens remaining in the subscriber’s CBS (or PBS) bucket. The total number of tokens can not be greater than the burst size. If the total number of tokens is greater than the burst size, the number is set to equal the burst size.

After passing through the Token Bucket Algorithm, the packet is internally classified with a color, as follows:

•	If there are not enough tokens in the PBS bucket to allow a packet to pass, the packet is considered to be in violation and is marked “red” and the violation counter is incremented by one.

•	If there are enough tokens in the PBS bucket to allow a packet to pass, but not in the CBS “bucket”, then the packet is considered to be in excess and is marked “yellow”, the PBS bucket is decremented by the packet size, and the exceed counter is incremented by one.

•	If there are more tokens present in the CBS bucket than the size of the packet, then the packet is considered as conforming and is marked “green” and the CBS and PBS buckets are decremented by the packet size.

The system can be configured with actions to take for red and yellow packets. Any of the following actions may be specified:

•	Drop: The offending packet is discarded.

•	Transmit: The offending packet is passed.

•	Lower the IP Precedence: The packet's ToS octet is set to “0”, thus downgrading it to Best Effort, prior to passing the packet.

Different actions can be specified for red and yellow, as well as for uplink and downlink directions and for different 3GPP traffic classes.

 

DSCP Marking for IPSec Access

The Differentiated Service Code Point (DSCP) marking feature on the PDG/TTG provides support for more granular configuration of DSCP marking.

The PDG/TTG functioning as a TTG can perform DSCP marking of packets sent over the Wu interface in the downlink direction to the WLAN UEs and over the Gn' interface in the uplink direction to the GGSN.

In the PDG Service Configuration Mode of the system’s CLI, you use the ip qos-dscp command to control DSCP markings for downlink packets sent over the Wu interface in IPSec tunnels, and use the ip gnp-qos-dscp command to control DSCP markings for uplink packets sent over the Gn' interface in GTP tunnels.

The DSCP markings are applied to the IP header of every transmitted subscriber data packet. DSCP levels can be assigned to specific traffic patterns in order to ensure that the data packets are delivered according to the precedence with which they are tagged. The four traffic patterns have the following order of precedence: background (lowest), interactive, streaming, and conversational (highest).

For the interactive traffic class, the PDG/TTG supports per-gateway service and per-APN configurable DSCP marking for the uplink and downlink directions based on Allocation/Retention Priority in addition to the current priorities.

The following matrix can be used to determine the DSCP markings used based on the configured traffic class and Allocation/Retention Priority:

Default DSCP Value Matrix

Allocation Priority	1	2	3
Traffic Handling Priority
1	ef	ef	ef
2	af21	af21	af21
3	af21	af21	af21

‌

You can assign DSCP to specific traffic patterns to ensure that data packets are delivered according to the precedence with which they are tagged. The diffserv markings are applied to the outer IP header of every GTP data packet. The diffserv marking of the inner IP header is not modified.

The traffic patterns are defined by QCI (1 to 9). Data packets falling under the category of each of the traffic patterns are tagged with a DSCP that further indicate their precedence as shown in the following tables :

Class structure for assured forwarding (af) levels

Drop Precedence	Class
	Class 1	Class 2	Class 3	Class 4
Low	af11	af21	af31	af41
Medium	af12	af22	af32	af41
High	af13	af23	af33	af43

‌

DSCP Precedence

Precedence (low to high)	DSCP
0	Best Effort (be)
1	Class 1
2	Class 2
3	Class 3
4	Class 4
5	Express Forwarding (ef)

‌

 

WLAN Access Control

The PDG/TTG enables WLAN access control by enabling you to limit the number of IKEv2/IPSec tunnels per subscriber session.

In the PDG Service Configuration Mode of the system’s CLI, the max-tunnels-per-ue command can be used to specify the maximum number of IKEv2/IPSec tunnels per subscriber session.

The number of tunnels per UE is limited by the Network Service Access Point Identifier (NSAPI) range, which is 5 to 15. Hence, the configurable maximum number of tunnels is 11, within the range of 1 to 11, with a default value of 11.

 

RADIUS and Diameter Support

RADIUS and Diameter support on the PDG/TTG provides a mechanism for performing authentication, authorization, and accounting (AAA) for subscribers. The benefits of using AAA are:

 

•	Higher flexibility for subscriber access control

•	Better accounting, charging, and reporting options

•	Industry-standard RADIUS and Diameter authentication

The Remote Authentication Dial-In User Service (RADIUS) and Diameter protocols can be used to provide AAA functionality for subscribers. The PDG/TTG supports EAP authentication based on both RADIUS and Diameter protocols.

The AAA functionality on the PDG/TTG provides a wide range of configuration options via AAA server groups, which allow a number of RADIUS/Diameter parameters to be configured in support of the PDG service.

Currently, two types of authentication load-balancing methods are supported: first-server and round-robin. The first-server method sends requests to the highest priority active server. A request will be sent to a different server only if the highest priority server is not reachable. With the round-robin method, requests are sent to all active servers in a round-robin fashion.

The PDG/TTG can detect the status of the AAA servers. Status checking is enabled by configuration in the AAA Server Group Configuration Mode of the system’s CLI. Once an AAA server is detected to be down, it is kept in the down state up to a configurable duration of time called the dead-time period. After the dead-time period expires, the AAA server is eligible to be retried. If a subsequent request is directed to that server and the server properly responds to the request, the system makes the server active again.

The PDG/TTG generates accounting messages on successful session establishment. For a TTG session, the system creates an IPSec SA for a subscriber session after it creates the GTP tunnel to the GGSN over the Gn' interface. The TTG sends an accounting START message to the AAA server after successful completion of both GTP tunnel creation on the Gn' interface and IPsec SA creation on the Wu interface.

 

Additional Command Option for APN Configuration for Diameter AAA

For APN configuration for Diameter AAA on the PDG, the APN profile can specify whether the PDG combines authentication and authorization in the same access request to the AAA server, or sends an authentication access request followed by a separate authorization access request. The command syntax for this authentication command option in the APN Configuration Mode of the system CLI is:

authentication eap initial-access-request { authenticate-authorize | authenticate-only }

When set to authenticate-authorize, the PDG performs EAP authentication and authorization using a Diameter DER-DEA message exchange for all subscribers requesting access to the specified APN. When set to authenticate-only, the PDG performs authentication only using a Diameter DER-DEA message exchange. A successful authentication will be followed by a separate authorization access request via an AAR-AAA message exchange.

This command option applies to the PDG/TTG in PDG mode only.

Important: For more information on AAA configuration, refer to the AAA and GTPP Interface Administration and Reference.

 

EAP Fast Re-authentication Support

When subscriber authentication is performed frequently, it can lead to a high network load, especially when the number of currently connected subscribers is high. To address this issue, the PDG/TTG can employ fast re-authentication, which is a more efficient method than full authentication.

Fast re-authentication is an EAP (Extensible Authentication Protocol) exchange that is based on keys derived from a preceding full authentication exchange. The fast re-authentication mechanism can be used during both EAP-AKA and EAP-SIM authentication.

When fast re-authentication is enabled, the PDG/TTG receives a fast re-auth ID from the UE in the IDi payload of the IKE_AUTH_REQ message. The PDG/TTG sends the fast re-auth ID to the AAA server in an Authentication Request message to initiate fast re-authentication.

During fast re-authentication, the PDG/TTG handles two separate IKE/IPSec SAs, one for the original session and one for re-authentication. The re-authentication SA remains for a very short period until the fast re-authentication is successful. After the successful fast re-authentication, the PDG/TTG assigns the UE with the same IP address. The SGTP service running on the PDG/TTG identifies the original session and replicates the same session using the same IP address assignment. The PDG/TTG then deletes the original session SA.

The AAA server falls back to full authentication in the following scenarios:

•	When the AAA server does not support fast re-authentication.

•	When the number of times a fast re-authentication is allowed after a successful full authentication exceeds the limit configured on the AAA server.

•	When the EAP server does not have the permanent subscriber identity to perform a fast re-authentication.

 

Pseudonym NAI Support

The PDG/TTG supports the use of pseudonym Network Access Identifiers (NAIs) to protect the identity of subscribers against tracing from unauthorized access networks.

Pseudonym NAIs are allocated to the WLAN UEs by the EAP server along with the last successful full authentication. The EAP server maintains the mapping of pseudonym-to-permanent identity for each subscriber. The UEs store this mapping in non-volatile memory to save it across reboots, and then use the pseudonym NAI instead of the permanent one in responses to identity requests from the EAP server.

 

Multiple APN Support for IPSec Access

The PDG/TTG supports multiple wireless APNs for the same UE (the same IMSI) for use during subscriber authorization.

To support subscribers while they attempt to access multiple services, the PDG/TTG enables multiple subscriber authorizations via multiple wireless APNs. Each time a UE attempts to access a service, the PDG/TTG receives a new APN from the UE in the IDr payload of its first IKE_AUTH_REQ message, and the PDG/TTG initiates a new authorization as a distinct session.

 

Multiple Authentication Support

The PDG/TTG operating in PDG mode supports multiple authentication phases per TS 23.234 and RFC 4739. For EAP protocol, the PDG service operates in authenticator pass-through mode. For PAP and CHAP protocols, the PDG service operates in EAP authenticator terminator mode. The PDG exchanges authentication credentials on the access side using EAP-GTC for PAP payloads and EAP-MD5 for CHAP payloads, and on the PDN side, it exchanges the same parameters inside RADIUS or Diameter AAA protocol messages.

When an APN access request received from a WLAN UE requires authentication and authorization, the PDG negotiates with the UE to determine whether it supports multiple authentication exchanges in IKEv2 protocol. If the UE supports multiple authentication exchanges, and if the UE requests additional authentication with the 3GPP AAA server after successful initial EAP authentication, the PDG performs the next phase of authentication with the external AAA server.

The PDG requests additional authentication of the UE from the external AAA server as follows:

 

•	If an EAP procedure is required (EAP profile = AKA/SIM), the PSG performs a second phase authentication similar to the first phase authentication using EAP-AKA or EAP-SIM. If the PDG receives a Legacy-Nak response from the UE, the PDG sends an EAP-Failure message to the UE.

•

If a PAP procedure is required (EAP profile = GTC), the PDG sends an EAP-GTC request to the UE. Upon receiving an EAP-GTC response from the UE within an IKE_AUTH request, the PDG performs the next phase authentication with the AAA server. If the PDG receives a Legacy-Nak response containing the type EAP-MD5, and if the specified W-APN allows it, the PDG changes the authentication and authorization procedure to CHAP. If the specified W-APN does not allow CHAP procedures or if the PDG receives a Legacy-Nak response that does not contain EAP-MD5, the PDG sends an EAP-Failure message to the UE.

•

If a CHAP procedure is required (EAP profile = MD5), the PDG sends an MD5-Challenge request to the UE. Upon receiving an MD5-Challenge response from the UE within an IKE_AUTH request, the PDG performs the next phase authentication with the AAA server. If the PDG receives a Legacy-Nak response containing the type EAP-GTC, and if the specified W-APN allows it, the PDG changes the authentication and authorization procedure to PAP. If the specified W-APN does not allow PAP procedures or if the PDG receives a Legacy-Nak response that does not contain EAP-GTC, the PDG sends an EAP-Failure message to the UE.

 

Fast Re-authentication and Pseudonym Re-authentication

After a successful call set-up, if the UE sends a re-authentication request to the PDG using fast re-authentication or pseudonym re-authentication (received in the first phase EAP authentication in the IDi payload of the IKE_AUTH message), the PDG performs EAP-based re-authentication with the 3GPP AAA server. If the UE sends an ANOTHER_AUTH_FOLLOWS Notify payload and IDi for a second phase authentication after that, the PDG performs a second phase authentication with the external AAA server. If the UE sends a re-authentication request to the PDG using fast re-authentication or pseudonym re-authentication (received in the second phase EAP authentication in the IDi payload of the IKE_AUTH message), the PDG drops the call. In the case of PAP and CHAP, neither the UE nor the PDG initiate re-authentication for a second phase authentication directly.

 

Re-authorization and RADIUS CoA Handling

An AAA-initiated change-of-authorization / re-authorization for the external AAA server is handled in the same way as is handled for the 3GPP AAA server.

 

Message Flows and Configuration Instructions

For detailed message flows of multiple authentication scenarios on the PDG, see the section How the PDG/TTG Works later in this chapter.

Multiple authentication support is configured on the PDG on a W-APN basis. For configuration instructions, see Chapter 2.

 

Lawful Intercept

The Cisco Lawful Intercept feature is supported on the PDG/TTG. Lawful Intercept is a license-enabled, standards-based feature that provides telecommunications service providers with a mechanism to assist law enforcement agencies in monitoring suspicious individuals for potential illegal activity. For additional information and documentation on the Lawful Intercept feature, contact your sales representative.

 

IMS Emergency Call Handling

The PDG/TTG supports IMS emergency call handling per 3GPP TS 33.234. This feature is enabled by configuring a special WLAN access point name (W-APN), which includes a W-APN network identifier for emergency calls (sos, for example), and can be configured with no authentication.

The DNSs in the network are configured to resolve the special W-APN to the IP address of the PDG/TTG. When a WLAN UE initiates an IMS emergency call, the UE sends a W-APN that includes the same W-APN network identifier (sos) as the one that is configured on the PDG/TTG. This W-APN network identifier is prefixed to the W-APN operator identifier per 3GPP TS 23.003. The W-APN operator identifier sent by the UE must match the PLMN ID (MCC and MNC) that is configured on the PDG/TTG (visited network). When the PDG/TTG receives the W-APN from the UE in the IDr, the PDG/TTG marks the call as an emergency call and proceeds with call establishment, even in the event of an authentication or EAP failure from the AAA/EAP server.

If the PDG/TTG detects that an old IKE SA for the special W-APN already exists, it deletes the IKE SA and sends an INFORMATIONAL message with a Delete payload to the WLAN UE to delete the old IKE SA on the UE.

 

Session Recovery Support

The session recovery feature is a licensed feature on the PDG/TTG. It provides seamless failover and nearly instantaneous reconstruction of subscriber session information in the event of a hardware or software fault within the same chassis, preventing a fully-connected user session from being dropped. For information about the required software license for this feature, contact your sales representative.

Session recovery is performed by mirroring key software processes (the IPSec manager, session manager, and AAA manager, for example) on the PDG/TTG. These mirrored processes remain in an idle state (in standby mode), where they perform no processing until they may be needed in the case of a software failure (a session manager task aborts, for example). The system spawns new instances of standby mode sessions and AAA managers for each active control processor being used.

Additionally, other key system-level software tasks such as VPN manager are performed on a physically separate packet processing card to ensure that a double software fault (the session manager and the VPN manager fail at same time on same card, for example) cannot occur. The packet processing card used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled. At a minimum, four packet processing cards (3 active and 1 standby) are required on the chassis to support the session recovery feature.

Important: For more information about session recovery support, refer to the Session Recovery chapter in this guide.

 

Congestion Control

Congestion control allows you to set policies and thresholds and specify how the system reacts when faced with a heavy load condition.

Congestion control monitors the system for conditions that could potentially degrade performance when the system is under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an impact on the system’s ability to service subscriber sessions. Congestion control helps identify such conditions and invokes policies for addressing the situation.

Congestion control operation is based on configuring the following:

•

Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled and establishes limits for defining the state of the system (congested or clear). These thresholds function in a way similar to operation thresholds that are configured for the system as described in the Thresholding Configuration Guide. The primary difference is that when congestion thresholds are reached, a service congestion policy and an SNMP trap, starCongestion, are generated.

A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for the condition to be cleared. An SNMP trap, starCongestionClear, is then triggered.

•	Port Utilization Thresholds: If you set a port utilization threshold, when the average utilization of all ports in the system reaches the specified threshold, congestion control is enabled.

•	Port-specific Thresholds: If you set port-specific thresholds, when any individual port-specific threshold is reached, congestion control is enabled system-wide.

•	Service Congestion Policies: Congestion policies are configurable for each service. These policies dictate how services respond when the system detects that a congestion condition threshold has been crossed.

Important: For more information on congestion control, refer to the Congestion Controlchapter in this guide.

 

Bulk Statistics

Bulk statistics allow operators to choose to view not only statistics that are of importance to them, but to also configure the format in which they are presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.

When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.

The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. The following is a partial list of supported schemas:

 

•	System: Provides system-level statistics

•	Card: Provides card-level statistics

•	Port: Provides port-level statistics

•	PDG: Provides PDG service statistics

•	APN: Provides Access Point Name statistics

The system supports the configuration of up to four sets (primary/secondary) of receivers. Each set can be configured to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the system or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.

The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, system host name, system uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.

When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.

The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a northbound NMS or an alternate bulk statistics server for further processing.

Additionally, if archiving of the collected statistics is desired, the Bulk Statistics Server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.

Important: For more information on bulk statistic configuration, refer to the Configuring and Maintaining Bulk Statistics chapter of the System Administration Guide.

 

Threshold Crossing Alerts

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outages. Typically, these conditions are temporary (i.e., high CPU utilization or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.

The system supports threshold crossing alerts for certain key resources such as CPU, memory, IP pool addresses, etc. With this capability, the operator can configure a threshold on these resources whereby, should the resource depletion cross the configured threshold, an SNMP trap would be sent.

The following thresholding models are supported by the system:

 

•	Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated, then generated and/or sent again at the end of the polling interval.

•	Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated, then generated and/or sent again at the end of the polling interval.

Thresholding reports conditions using one of the following mechanisms:

 

•

SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values. Generation of specific traps can be enabled or disabled on the chassis, ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.

•

Logs: The system provides a facility for which active and event logs can be generated. As with other system facilities, logs are generated messages pertaining to the condition of a monitored value and are generated with a severity level of WARNING. Logs are supported in both the Alert and the Alarm models.

•

Alarm System: High threshold alarms generated within the specified polling interval are considered outstanding until a condition no longer exists or a condition clear alarm is generated. Outstanding alarms are reported to the system’s alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.

Important: For more information on threshold crossing alert configuration, refer to the Thresholding Configuration Guide.

 

AAA Mediation and Offline Charging

Offline charging is a process where charging information is collected at the same time as resource use. The charging information is then passed through a chain of charging functions. At the end of the process, CDR files are generated by the network, which are then transferred to the network operator’s billing domain.

The charging trigger function (CTF) generates charging events and forwards them to the charging data function (CDF). The CDF, in turn, generates CDRs which are transferred to the charging gateway function (CGF). Finally, the CGF creates CDR files and forwards them to the billing domain. The CTF and CDF are integrated in the PDG, however, the CGF may exist as a separate entity or be integrated with the PDG. If the CGF is external to the PDG then the CDF forwards the CDRs to the CGF using the GTPP protocol.

In theASR5000, the PDG is integrated with the CTF and CDF and generates WLAN-CDRs based on triggered events over the Wz interface. The PDG offline charging involves the following functionalities for WLAN 3GPP IP access:

 

•	Charging Trigger Function

•	Charging Data Function

•	Wz Reference Point

 

Accounting Session Management

The WLAN-CDR is generated as part of AAAmgr accounting management in PDG. When the Accounting-Mode is set to GTPP, it indicates that the charging is enabled and the Wz reference point is to be used for passing charging records to the CGF.

 

Triggers for WLAN CDRs Charging Information

The PDG/TTG uses the charging characteristics to determine whether to activate or deactivate CDR generation. The charging characteristics al set the chargeable event conditions, such as the time/volume limits that trigger CDR generation or the addition of information. Multiple charging characteristics profiles may be configured on the PDG to allow different sets of trigger values.

 

Triggers for WLAN-CDR Closure

The following events trigger closure and sending of a partial WLAN-CDR:

 

•	Time trigger: every x seconds configured using interval x.

•	Volume trigger: every x octets configured using volume x

•	The command gtpp interim now

A WLAN-CDR is closed as the final record of a session for the following events:

 

•	normalRelease: UE terminates the IPSec tunnel. The call is handed from one PDG to another PDG.

•	abnormalRelease: Failure due to multiple software failures.

•	volumeLimit: The configured volume threshold has been exceeded.

•	timeLimit: the configured interval has been reached.

•	maxChangeCondition: the limit for the LOTV containers has been exceeded.

•	managementIntervention: The command gtpp interim now has been issued.

•	managementIntervention: The command clear sub all has been issued.

 

Triggers for WLAN-CDRs Charging Information Addition

The List of Traffic Volumes attribute of the WLAN-CDR consists of a set of containers, which are added when specific trigger conditions are met. They identify the volume count per PDP context, and are separated for uplink and downlink traffic:

 

•	QoS Change: A change in the QoS results in closing the List of Traffic Data Volumes that were open. The volumes are added to the CDR and a new bearer-specific container is opened.

•	tariffTime: On reaching the Tariff Time Change, a List of Traffic Data Volumes container is added to the CDR.

•	recordClosure: A list of List of Traffic Data Volumes containers is added to the WLAN CDR.

 

Offline Charging Sample Configuration

The following is an example configuration to enable Offline Charging through PDG mode. This configuration .

configure

   context pdg

      #gtpp group related configuration

     gtpp group <group1>

        gtpp
charging-agent address < gtpp-server-ip >

         #Triggers Configuration

        gtpp trigger volume-limit

        #CDR attributes

        gtpp attribute local-record-sequence-number

       gtpp attriute msisdn

        gtpp attribute rat

     #Accounting Policy configuration

     policy accounting <acct1>

        <cc profile 3 volume total 20000>

     #PDG Service configuration

     pdg-service <pdgsrv>

        associate accounting-policy <acct1>

     #APN mode configuration     apn <apn_name>         accounting mode gtpp        gtpp group group1accounting-context <pdg>

exit

 

Features Not Supported in This Release

The following features are not supported in this PDG/TTG software release:

 

•	Link aggregation

•

IPv6

•

MPLS

•

NAT

•

Firewall

•	Peer-to-Peer

 

How the PDG/TTG Works

This section describes the PDG/TTG during connection establishment.

 

PDG Connection Establishment

The figure below shows the message flow during PDG connection establishment. The table that follows the figure describes each step in the message flow.

PDG Connection Establishment

 

PDG Connection Establishment

Step	Description
1.	After the UE connects to the WLAN and performs EAP authentication, the UE initiates an IKEv2/IPSec tunnel by sending an IKE_SA_INIT Request to the PDG. The UE includes the SA, KE, Ni, and NAT-Detection Notify payloads in the IKEv2 exchange.
2.	The PDG processes the IKE_SA_INIT Request for the appropriate PDG service (bound by the destination IP address in the IKEv2 INIT Request). The PDG responds with an IKE_SA_INIT Response with the SA, KE, and Nr payloads, and NAT-Detection Notify payloads. The PDG will start the IKEv2 setup timer when sending the IKE_SA_INIT Response. With the IKEv2 SA INIT exchanges, the WLAN UE negotiates cryptographic algorithms, exchanges the nonce, and performs a Diffie-Hellman exchange.
3.	Upon receiving a successful IKE_SA_INIT Response from the PDG, the UE sends an IKE_ AUTH Request for the first EAP-AKA authentication. The UE also includes an IDi payload, which contains the NAI, SA, TSi, TSr, CP (requesting an IP address and DNS address) payloads. The IDr payload is the requested W-APN. The UE does not include AUTH payload to indicate that it will use the EAP method. The NAI can either be the IMSI or a pseudonym.
4.	Upon receiving the IKE_AUTH Request from UE, the PDG sends an Authentication Request (RADIUS Access Request or DER) message to the AAA server. The PDG sends the Authentication Request message with an EAP (Identity Response) AVP to the AAA server, including the user identity and W-APN. The W-APN information is included in the called-station-id RADIUS attribute in all Access-Request messages towards the AAA server. The PDG includes a parameter indicating that the authentication is being performed for tunnel establishment. This helps the AAA server to distinguish between authentications for WLAN access and authentications for tunnel setup. The PDG starts the session setup timer upon receiving the IKE_AUTH Request from the UE. Note that the PDG sends the W-APN received in the IDr payload in IKEv2 messages as is to the AAA server. This helps the AAA server to look up the authorization database based on the W-APN name. When sending messages to the HLR (or HSS), the AAA server maps the W-APN name into the real APN configured in the HLR (or HSS).
5.	The AAA server initiates the authentication challenge. The user identity is not requested again, as in a normal authentication process, because there is the certainty that the user identity received in the EAP Identity Response message has not been modified or replaced by any intermediate node. This is because the user identity is received via an IKEv2 secure tunnel which can only be decrypted and authenticated by the end points (the PDG and the WLAN UE). The PDG receives a DEA with a Result-Code AVP specifying to continue EAP authentication. For RADIUS, this is an access challenge message. The PDG accepts the EAP-Payload AVP contents.
6.	The PDG sends an IKE_ AUTH Response back to the UE in the EAP payload. Depending upon the configuration, the PDG can include IDr (PDG-ID) and CERT payloads. The PDG allows IDr and CERT configurations in the PDG service. If the PDG service is configured to do so, the PDG can also include an AUTH payload in the IKE_AUTH Response. The UE receives the IKE_AUTH Response from PDG.
7.	Upon receiving the IKE_AUTH Response from the PDG, the UE processes the exchange and sends a new IKE_AUTH Request with an EAP payload. The PDG receives the new IKE_AUTH Request from the UE.
8.	The PDG sends a DER (or RADIUS AR) message to the AAA server. This DER message contains the EAP-Payload AVP with an EAP-AKA challenge or EAP-SIM challenge response and challenge received from the UE.
9.	The AAA server sends the DEA back to the PDG with Result-Code AVP as Success. The EAP-Payload AVP message also contains an EAP result code as Success. The PDG also receives the MSK (keying materials) from the AAA server, which is used for further key computation. When using Diameter, the MSK is encapsulated in the EAP-Master-Session-Key parameter. The AAA server also includes several authorization AVPs. When the checks for an IMS emergency call fail, the AAA Server also sends an Authentication Answer that includes an EAP Failure to the PDG.
10.	The PDG sends the IKE_AUTH Response back to UE with the EAP payload.
11.	The UE sends the final IKE_AUTH Request with the AUTH payload computed from the keys. The PDG uses the MSK to generate the AUTH parameters in order to authenticate the IKE_SA_INIT phase messages. These first two messages had not been authenticated before as there was no key material available yet. When used over IKEv2, the shared secret generated in the EAP exchange (the MSK) is used to generate the AUTH parameters. The PDG processes the IKE_AUTH Request, checks the validity of AUTH payload, allocates an IP address for the UE, establishes an IPSec SA, install the Internet-side flows, and links them for the user traffic.
12.	The PDG sends a Diameter Accounting-Request (START) message to the AAA server. For RADIUS, it sends an Accounting-Start message.
13.	Upon receiving the Accounting-Request message, the AAA server sends an Accounting-Response reply to the PDG. For RADIUS, it sends an Accounting-Stop message.
14.	The PDG sends an IKE_AUTH Response with the AUTH payload computed from the MSK. The PDG assigns the IP address to the UE in the configuration payload along with DNS addresses and other parameters.
15.	The PDG session/IPSec SA is fully established and ready for data transfer.

‌

 

TTG Connection Establishment

The figure below shows the message flow during TTG connection establishment. The table that follows the figure describes each step in the message flow.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

TTG Connection Establishment

 

 

TTG Connection Establishment

Step	Description
1.	After receiving the IP address of the TTG from the WiFi access point, the UE initiates an IKEv2/IPSec tunnel by sending an IKE_SA_INIT Request to the TTG. The UE includes the SA, KE, Ni, and NAT-Detection Notify payloads in the IKEv2 exchange.
2.	The TTG processes the IKE_SA_INIT Request for the appropriate PDG service (bound by the destination IP address in the IKEv2 INIT Request). The TTG responds with an IKE_SA_INIT Response with the SA, KE, and Nr payloads, and NAT-Detection Notify payloads. The TTG will start the IKEv2 setup timer when sending the IKE_SA_INIT Response. With the IKEv2 SA INIT exchanges, the WLAN UE negotiates cryptographic algorithms, exchanges the nonce, and performs a Diffie-Hellman exchange.
3.	Upon receiving a successful IKE_SA_INIT Response from the TTG, the UE sends an IKE_ AUTH Request for the first EAP-AKA authentication. The UE also includes an IDi payload, which contains the NAI, SA, TSi, TSr, CP (requesting an IP address and DNS address) payloads. The IDr payload is the requested W-APN. The UE does not include AUTH payload to indicate that it will use the EAP method. The NAI can either be the IMSI or a pseudonym.
4.	Upon receiving the IKE_AUTH Request from UE, the TTG sends an Authentication Request (RADIUS Access Request or DER) message to the AAA server. The TTG sends the Authentication Request message with an EAP (Identity Response) AVP to the AAA server, including the user identity and W-APN. The W-APN information is included in the called-station-id RADIUS attribute in all Access-Request messages towards the AAA server. The TTG includes a parameter indicating that the authentication is being performed for tunnel establishment. This helps the AAA server to distinguish between authentications for WLAN access and authentications for tunnel setup. The TTG starts the session setup timer upon receiving the IKE_AUTH Request from the UE. Note that the TTG sends the W-APN received in the IDr payload in IKEv2 messages as is to the AAA server. This helps the AAA server to look up the authorization database based on the W-APN name. When sending messages to the HLR (or HSS), the AAA server maps the W-APN name into the real APN configured in the HLR (or HSS).
5.	The AAA server initiates the authentication challenge. The user identity is not requested again, as in a normal authentication process, because there is the certainty that the user identity received in the EAP Identity Response message has not been modified or replaced by any intermediate node. This is because the user identity is received via an IKEv2 secure tunnel which can only be decrypted and authenticated by the end points (the TTG and the WLAN UE). The TTG receives a DEA with a Result-Code AVP specifying to continue EAP authentication. For RADIUS, this is an access challenge message. The TTG accepts the EAP-Payload AVP contents.
6.	The TTG sends an IKE_ AUTH Response back to the UE in the EAP payload. Depending upon the configuration, the TTG can include IDr (TTG-ID) and CERT payloads. The TTG allows IDr and CERT configurations in the PDG service. If the PDG service is configured to do so, the TTG can also include an AUTH payload in the IKE_AUTH Response. The UE receives the IKE_AUTH Response from TTG.
7.	Upon receiving the IKE_AUTH Response from the TTG, the UE processes the exchange and sends a new IKE_AUTH Request with an EAP payload. The TTG receives the new IKE_AUTH Request from the UE.
8.	The TTG sends a DER (or RADIUS AR) message to the AAA server. This DER message contains the EAP-Payload AVP with an EAP-AKA challenge or EAP-SIM challenge response and challenge received from the UE.
9.	The AAA server sends the DEA back to the TTG with Result-Code AVP as Success. The EAP-Payload AVP message also contains an EAP result code as Success. The TTG also receives the MSK (keying materials) from the AAA server, which is used for further key computation. When using Diameter, the MSK is encapsulated in the EAP-Master-Session-Key parameter. The AAA server also includes several authorization AVPs. When the checks for an IMS emergency call fail, the AAA Server also sends an Authentication Answer that includes an EAP Failure to the TTG. Note that steps 9a. and 9b. (described below) may not be required if authorization attributes or AVPs are present in the Access-Accept message containing the EAP-Success. As explained in step 5 above, if the W-APN is present in all the Access-Request messages from the TTG to the AAA server, the AAA server can use the W-APN to look up the authorization database to retrieve the parameters. If the TTG has done the W-APN-to-real-APN mapping and includes the mapped APN in the AAA messages, the TTG performs steps 9a. and 9b., and includes the W-APN in a separate message after successful EAP-authentication. 9a. The TTG sends an Authorization Request message with an empty EAP AVP, but containing the W-APN, to the AAA server. The AAA server checks the user's subscription information whether the user is authorized to establish a tunnel. The IKE SA counter for that W-APN is incremented. If the maximum number of IKE SAs for that W-APN is exceeded, the AAA server sends an indication to the TTG that established the oldest active IKE SA (it could be the same TTG or a different one) to delete the oldest established IKE SA. The AAA server then updates the counters tracking the active IKE SAs for the W-APN accordingly. 9b. The AAA server sends the AA-Answer to the TTG. The AAA server sends the IMSI within the AA-Answer.
10.	The TTG sends the IKE_AUTH Response back to UE with the EAP payload.
11.	The UE sends the final IKE_AUTH Request with the AUTH payload computed from the keys. The TTG uses the MSK to generate the AUTH parameters in order to authenticate the IKE_SA_INIT phase messages. These first two messages had not been authenticated before as there was no key material available yet. When used over IKEv2, the shared secret generated in the EAP exchange (the MSK) is used to generate the AUTH parameters. The TTG processes the IKE_AUTH Request, checks the validity of AUTH payload, and initiates PDP context activation with the GGSN.
12.	The TTG sends a Create PDP Context Request to the GGSN. The GGSN processes the request and assigns an IP address to the UE.
13.	The GGSN sends a Create PDP Context Response to the TTG. The TTG sets up an IPSec SA.
14.	The TTG sends an IKE_AUTH Response with the AUTH payload computed from the MSK. The TTG assigns the IP address received from the GGSN to the UE in the configuration payload along with DNS addresses and other parameters.
15.	The TTG session/IPSec SA is fully established and ready for data transfer.

‌

 

Multiple Authentication Using EAP and PAP

The figure below shows the message flow during PDG connection establishment with multiple authentication. This message flow shows the PDG performing first-phase authentication using EAP (EAP-AKA or EAP-SIM) over Diameter protocol and second-phase authentication using PAP (EAP-GTC) over RADIUS protocol.

Multiple Authentication Using EAP and PAP

 

Multiple Authentication Using EAP and CHAP

The figure below shows the message flow during PDG connection establishment with multiple authentication. This message flow shows the PDG performing first-phase authentication using EAP (EAP-AKA or EAP-SIM) over Diameter protocol and second-phase authentication using CHAP (EAP-MD5) over RADIUS protocol.

Multiple Authentication Using EAP and CHAP

 

Multiple Authentication Using EAP and EAP

The figure below shows the message flow during PDG connection establishment with multiple authentication. This message flow shows the PDG performing first-phase authentication using EAP (EAP-AKA or EAP-SIM) over Diameter protocol and second-phase authentication using EAP (EAP-AKA or EAP-SIM) over RADIUS protocol.

Multiple Authentication Using EAP and EAP

 

Multiple Authentication with Request from UE for Change of Second Phase Protocol

The figure below shows the message flow during PDG connection establishment with multiple authentication. This message flow shows a scenario in which the UE does not support EAP-MD5. When the PDG sends an EAP-MD5 challenge, the UE sends an EAP Legacy-Nak requesting that the PDG use EAP-GTC instead. The first phase authentication is over Diameter protocol and the second phase authentication is over RADIUS protocol.

Multiple Authentication with Request from UE for Change of Second Phase Protocol

 

Supported Standards

The PDG/TTG complies with the following standards.

 

•	3GPP References

•	IETF References

 

3GPP References

 

•	3GPP TS 22.234 (V8.1.0): “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Requirements on 3GPP system to Wireless Local Area Network (WLAN) interworking (Release 7)”.

•	3GPP TS 23.003 (V7.9.0): “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 7)”.

•	3GPP TS 23.234 (V6.10.0 and V7.5.0): “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP system to Wireless Local Area Network (WLAN) interworking; System description (Release 6)”.

•	3GPP TS 23.327 (V8.4.0): “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Mobility between 3GPP-Wireless Local Area Network (WLAN) interworking and 3GPP systems (Release 8)”.

•	3GPP TS 24.234 (V8.3.0): “Group Core Network and Terminals; 3GPP System to Wireless Local Area Network (WLAN) interworking; WLAN User Equipment (WLAN UE) to network protocols; Stage 3 (Release 8)”.

•	3GPP TS 29.060 (V7.9.0): “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 7)”.

•	3GPP TS 29.234 (V8.1.0): “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP system to Wireless Local Area Network (WLAN) interworking; Stage 3 (Release 8)”.

•	3GPP TS 32.252 (V7.0.0): “3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Wireless Local Area Network (WLAN) charging (Release 7)”.

•	3GPP TS 33.234 (V6.9.0): “3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; 3G Security; Wireless Local Area Network (WLAN) interworking security (Release 6)”.

 

 

 

IETF References

 

•	RFC 2104 (February 1997): “HMAC: Keyed-Hashing for Message Authentication”.

•	RFC 2246 (January 1999): “The TLS Protocol, Version 1.0”.

•	RFC 2401 (November 1998): “Security Architecture for the Internet Protocol”.

•	RFC 2403 (November 1998): “The Use of HMAC-MD5-96 within ESP and AH”.

•	RFC 2404 (November 1998): “The Use of HMAC-SHA-1-96 within ESP and AH”.

•	RFC 2405 (November 1998): “The ESP DES-CBC Cipher Algorithm With Explicit IV”.

•	RFC 2451 (November 1998): “The ESP CBC-Mode Cipher Algorithms”.

•	RFC 3526 (May 2003): “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)”.

•	RFC 3539: (June 2003): “Authentication, Authorization and Accounting (AAA) Transport Profile”.

•	RFC 3602 (September 2003): “The AES-CBC Cipher Algorithm and Its Use with IPSec”.

•	RFC 3706 (February 2004): “A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers”.

•	RFC 4186 (January 2006): “Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)”.

•	RFC 4187 (January 2006): “Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)”.

•	RFC 4301 (December 2005): “Security Architecture for the Internet Protocol”.

•	RFC 4302 (December 2005): “IP Authentication Header”.

•	RFC 4303 (December 2005): “IP Encapsulating Security Payload (ESP)”.

•	RFC 4305 (December 2005): “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)”.

•	RFC 4306 (December 2005): “Internet Key Exchange (IKEv2) Protocol”.

•	RFC 4307 (December 2005): “Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)”.

•	RFC 4308 (December 2005): “Cryptographic Suites for IPSec”.

•	RFC 4478 (April 2006): “Repeated Authentication in Internet Key Exchange (IKEv2) Protocol”.

•	RFC 4718 (October 2006): “IKEv2 Clarifications and Implementation Guidelines”.

•	RFC 4835 (April 2007): “Cryptographic Algorithm Implementation RFC Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)”.

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883